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Abstract 


In existing specifications, the route preferences for IPv4/IPv6 
Extended Reachability TLVs are not explicitly stated. There are also 
inconsistencies in the definition of how the up/down bit applies to 
route preference when the prefix advertisement appears in Level 2 
Link State Protocol Data Units (LSPs). This document addresses these 
issues. 


This document updates RFC 5308. 
Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7775. 
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Les 


1. 


Introduction 


[RFC5302] defines the route preference rules as they apply to TLVs 
128 and 130. [RFC5305] introduced the IP Extended Reachability TLV 
135 but did not explicitly adapt the route preference rules defined 
in [RFC5302] for the new TLV. [RFC5308] defines the IPv6 
Reachability TLV 236 and does include an explicit statement regarding 
route preference -- but the statement introduces use of the up/down 
bit in advertisements that appear in Level 2 LSPs, which is 
inconsistent with statements made in [RFC5302] and [RFC5305]. This 
document defines explicit route preference rules for TLV 135, revises 
the route preference rules for TLV 236, and clarifies the usage of 
the up/down bit when it appears in TLVs in Level 2 LSPs. This 
document is a clarification (NOT a correction) of [RFC5302] and 
[RFC5305]; it is a correction of the route preference rules defined 
in [RFC5308] to be consistent with the rules for IPv4. It also makes 
explicit that the same rules apply to the Multi-Topology (MT) 
equivalent TLVs 235 and 237. 


1. Requirements Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


Use of the Up/Down Bit in Level 2 LSPs 


The up/down bit was introduced in support of leaking prefixes 
downwards in the IS-IS level hierarchy. Routes that are leaked 
downwards have the bit set to 1. Such prefixes MUST NOT be leaked 
upwards in the hierarchy. So long as we confine ourselves to a 
single IS-IS instance and the current number of supported levels 
(two), it is impossible to have a prefix advertised in a Level 2 LSP 
and have the up/down bit set to 1. However, because [RFC5302] 
anticipated a future extension to IS-IS that might support additional 
levels, it allowed for the possibility that the up/down bit might be 
set in a Level 2 LSP and supported easy migration in the event such 
an extension was introduced. Section 3.3 of [RFC5302] states: 


...it is RECOMMENDED that implementations ignore the up/down bit 
in L2 LSPs, and accept the prefixes in L2 LSPs regardless of 
whether the up/down bit is set. 


[RFC5305] addressed an additional case wherein an implementation 
included support for multiple virtual routers running IS-IS in 


different areas. In such a case, it is possible to redistribute 
prefixes between two IS-IS instances in the same manner that prefixes 
are redistributed from other protocols into IS-IS. This introduced 
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the possibility that a prefix could be redistributed from Level 1 to 
Level 1 (as well as between Level 2 and Level 2), and in the event 
the redistributed route was leaked from Level 1 to Level 2, two 
different routers in different areas would be advertising the same 
prefix into the Level 2 sub-domain. To prevent this, Section 4.1 of 
[RFC5305] specifies: 


If a prefix is advertised from one area to another at the same 
level, then the up/down bit SHALL be set to 1. 


However, the statement in [RFC5302] that the up/down bit is ignored 
in Level 2 LSPs is not altered by [RFC5305]. 


The conclusion then is that there is no "L2 inter-area route"; 
indeed, no such route type is defined by [RFC5302]. However, 
[RFC5308] ignored this fact and introduced such a route type in 
Section 5 when it specified a preference for "Level 2 down prefix". 
This is an error that this document corrects. As changing the use of 
the up/down bit in TLVs 236 and 237 may introduce interoperability 
issues, implementors may wish to support transition mechanisms from 
the behavior described in [RFC5308] to the behavior described in this 
document. 


3. Types of Routes in IS-IS Supported by Extended Reachability TLVs 


[RFC5302] is the authoritative reference for the types of routes 
supported by TLVs 128 and 130. However, a number of attributes 
supported by those TLVs are NOT supported by TLVs 135, 235, 236, and 
237. Distinction between internal/external metrics is not supported. 
In the case of IPv4 TLVs (135 and 235), the distinction between 
internal and external route types is not supported. However, the 
Prefix Attribute Flags sub-TLV defined in [PFXATTR] reintroduces the 
distinction between internal and external route types. The 
definitions below include references to the relevant attribute bits 
from [PFXATTR]. 


3.1. Types of Routes Supported by TLVs 135 and 235 
This section defines the types of route supported for IPv4 when using 


TLV 135 [RFC5305] and/or TLV 235 [RFC5120]. The text follows as 
closely as possible the original text from [RFC5302]. 


L1 intra-area routes: These are advertised in L1 LSPs, in TLV 135 or 
TLV 235. The up/down bit is set to 0. These IP prefixes are 
directly connected to the advertising router. If the Prefix 


Attribute Flags sub-TLV is included, both the X-Flag and the 
R-Flag are set to 0. 
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L1 external routes: These are advertised in L1 LSPs, in TLV 135 or 
TLV 235. The up/down bit is set to 0. These IP prefixes are 
learned from other protocols and are usually not directly 
connected to the advertising router. If the Prefix Attribute 
Flags sub-TLV is included, the X-Flag is set to 1, and the R-Flag 
is set to 0. 


L2 intra-area routes: These are advertised in L2 LSPs, in TLV 135 or 
TLV 235. The up/down bit is set to 0. These IP prefixes are 
directly connected to the advertising router. If the Prefix 


Attribute Flags sub-TLV is included, both the X-Flag and the 
R-Flag are set to 0. 


L1->L2 inter-area routes: These are advertised in L2 LSPs, in TLV 
135 or TLV 235. The up/down bit is set to 0. These IP prefixes 
are learned via L1 routing and were derived during the L1 Shortest 
Path First (SPF) computation from prefixes advertised in L1 LSPs 
in TLV 135 or TLV 235. If the Prefix Attribute Flags sub-TLV is 
included, the R-Flag is set to 1. 


L2->L2 inter-area routes: These are advertised in L2 LSPs, in TLV 
135 or TLV 235. The up/down bit is set to 1 but is ignored and 
treated as if it were set to 0. These IP prefixes are learned 
from another IS-IS instance usually operating in another area. If 
the Prefix Attribute Flags sub-TLV is included, the X-Flag is set 
to 1, and the R-Flag is set to 0. 


L2 external routes: These are advertised in L2 LSPs, in TLV 135 or 
TLV 235. The up/down bit is set to 0. These IP prefixes are 
learned from other protocols and are usually not directly 
connected to the advertising router. If the Prefix Attribute 
Flags sub-TLV is included, the X-Flag is set to 1, and the R-Flag 
is set to 0. 


L2->L1 inter-area routes: These are advertised in L1 LSPs, in TLV 
135 or TLV 235. The up/down bit is set to 1. These IP prefixes 
are learned via L2 routing and were derived during the L2 SPF 
computation from prefixes advertised in TLV 135 or TLV 235. If 
the Prefix Attribute Flags sub-TLV is included, the R-Flag is set 
to l. 


L1->L1 inter-area routes: These are advertised in L1 LSPs, in TLV 
135 or TLV 235. The up/down bit is set to 1. These IP prefixes 
are learned from another IS-IS instance usually operating in 
another area. If the Prefix Attribute Flags sub-TLV is included, 
the X-Flag is set to 1, and the R-Flag is set to 0. 
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3.2. Types of Routes Supported by TLVs 236 and 237 


This section defines the types of route supported for IPv6 when using 
TLV 236 [RFC5308] and/or TLV 237 [RFC5120]. 


L1 intra-area routes: These are advertised in L1 LSPs, in TLV 236 or 
TLV 237. The up/down bit is set to 0. The external bit is set to 
0. These IPv6 prefixes are directly connected to the advertising 
router. If the Prefix Attribute Flags sub-TLV is included, the 
R-Flag is set to 0. 


L1 external routes: These are advertised in L1 LSPs, in TLV 236 or 
TLV 237. The up/down bit is set to 0. The external bit is set to 
1. These IPv6 prefixes are learned from other protocols and are 
usually not directly connected to the advertising router. If the 
Prefix Attribute Flags sub-TLV is included, the R-Flag is set to 
0. 


L2 intra-area routes: These are advertised in L2 LSPs, in TLV 236 or 
TLV 237. The up/down bit is set to 0. The external bit is set to 
0. These IPv6 prefixes are directly connected to the advertising 
router. If the Prefix Attribute Flags sub-TLV is included, the 
R-Flag is set to 0. 


L1->L2 inter-area routes: These are advertised in L2 LSPs, in TLV 
236 or TLV 237. The up/down bit is set to 0. The external bit is 
set to 0. These IPv6 prefixes are learned via L1 routing and were 


derived during the L1 Shortest Path First (SPF) computation from 
prefixes advertised in L1 LSPs in TLV 236 or TLV 237. If the 
Prefix Attribute Flags sub-TLV is included, the R-Flag is set to 


1. 

L2 external routes: These are advertised in L2 LSPs, in TLV 236 or 
TLV 237. The up/down bit is set to 0. The external bit is set to 
1. These IPv6 prefixes are learned from other protocols and are 
usually not directly connected to the advertising router. If the 
Prefix Attribute Flags sub-TLV is included, the R-Flag is set to 
Oz 


L1->L2 external routes: These are advertised in L2 LSPs, in TLV 236 
or TLV 237. The up/down bit is set to 0. The external bit is set 
to 1. These IPv6 prefixes are learned via L1 routing and were 
derived during the L1 Shortest Path First (SPF) computation from 
L1 external routes advertised in L1 LSPs in TLV 236 or TLV 237. 

If the Prefix Attribute Flags sub-TLV is included, the R-Flag is 
set to 1. 
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3. 


L2->L2 inter-area routes: These are advertised in L2 LSPs, in TLV 


236 or TLV 237. The up/down bit is set to 1 but is ignored and 
treated as if it were set to 0. The external bit is set to l. 
These IP prefixes are learned from another IS-IS instance usually 
operating in another area. If the Prefix Attribute Flags sub-TLV 
is included, the R-Flag is set to 0. 


L2->L1 inter-area routes: These are advertised in L1 LSPs, in TLV 


236 or TLV 237. The up/down bit is set to 1. The external bit is 
set to 0. These IPv6 prefixes are learned via L2 routing and were 
derived during the L2 SPF computation from prefixes advertised in 
TLV 236 or TLV 237. If the Prefix Attribute Flags sub-TLV is 
included, the R-Flag is set to 1. 


L2->L1 external routes: These are advertised in L1 LSPs, in TLV 236 


or TLV 237. The up/down bit is set to 1. The external bit is set 
to 1. These IPv6 prefixes are learned via L2 routing and were 
derived during the L2 SPF computation from prefixes advertised in 
TLV 236 or TLV 237. If the Prefix Attribute Flags sub-TLV is 
included, the R-Flag is set to 1. 


L1->L1 inter-area routes: These are advertised in L1 LSPs, in TLV 


3. 


236 or TLV 237. The up/down bit is set to 1. The external bit is 
set to 1. These IP prefixes are learned from another IS-IS 
instance usually operating in another area. If the Prefix 
Attribute Flags sub-TLV is included, the R-Flag is set to 0. 


Order of Preference for All Types of Routes Supported by TLVs 135 
and 235 


This document defines the following route preferences for IPv4 routes 
advertised in TLVs 135 or 235. Note that all types of routes listed 
for a given preference are treated equally. 


Ti 


2. 


L1 intra-area routes; L1 external routes 


L2 intra-area routes; L2 external routes; L1->L2 inter-area 
routes; L2-L2 inter-area routes 


L2->L1 inter-area routes; L1->L1 inter-area routes 


Ginsberg, et al. Standards Track [Page 7] 


RFC 7775 IS-IS Route Preference February 2016 


3z 


5x 


De 


4. 


Order of Preference for All Types of Routes Supported by TLVs 236 
and 237 


This document defines the following route preferences for IPv6 routes 
advertised in TLVs 236 or 237. Note that all types of routes listed 
for a given preference are treated equally. 


Ts 


2. 


L1 intra-area routes; L1 external routes 


L2 intra-area routes; L2 external routes; L1->L2 inter-area 
routes; L1-L2 external routes; L2-L2 inter-area routes 


L2->L1 inter-area routes; L2->L1 external routes; L1->L1 inter- 
area routes 


Security Considerations 


This document raises no new security considerations. Security 
considerations for the IS-IS protocol are covered in [1S010589], 
[RFC5304], and [RFC5310]. 
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Appendix A. Example Interoperability Issue 


This example documents a real-world interoperability issue that 
occurs because implementations from different vendors have 
interpreted the use of the up/down bit in Level 2 LSPs 


inconsistently. 
L2 L2 L2 L2|L2 L2 
10/8 - RO ----- R1 ----- R2 ----- R3 ----- R4 ---- 10/8 


Figure 1 


In Figure 1, both RO and R4 are advertising the prefix 10/8. Two IS- 
IS Level 2 instances are running on R3 to separate the network into 


two areas. R3 is performing route leaking and advertises prefixes 
from R4 to the other Level 2 process. The network is using extended 
metrics (TLV 135 defined in [RFC5305]). RO advertises 10/8 with 


metric 2000, and R3 advertises 10/8 with metric 100. All links have 
a metric of 1. When advertising 10/8 in its Level 2 LSP, R3 sets the 
down bit as specified in [RFC5305]. 


R1, R2, and R3 are from three different vendors (R1->Vendorl1, 
R2->Vendor2, R3->Vendor3). During interoperability testing, routing 
loops are observed in this scenario. 


o R2 has two possible paths to reach 10/8: Level 2 route with metric 
2002 and up/down bit set to 0 (from RO) and Level 2 route with 
metric 101 and up/down bit set to 1 (from R3). R2 selects R1 as 
the next hop to 10/8 because it prefers the route that does NOT 
have the up/down bit set. 


o R3 has two possible paths to reach 10/8: Level 2 route with metric 
2003 and up/down bit set to 0 (from RO) and Level 2 route with 
metric 101 and up/down bit set to 0 (from R4). R3 selects R4 as 
the next hop due to lowest metric. 


o RI has two possible paths to reach 10/8: Level 2 route with metric 
2001 and up/down bit set to 0 (from RO) and Level 2 route with 
metric 102 and up/down bit set to 1 (from R3). R1 selects R2 as 
the next hop due to lowest metric. 


When R1 or R2 try to send traffic to 10/8, packets loop due to 
inconsistent routing decisions between R1 and R2. 
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